A recent development in third generation (3G) wireless communications is the long term evolution (LTE) cellular communication standard, sometimes referred to as 4th generation (4G) systems. Both of these technologies are compliant with third generation partnership project (3GPP™) standards. Irrespective of whether these LTE spectral allocations use existing second generation (2G) or 3G allocations being re-farmed for fourth generation (4G) systems, or new spectral allocations for existing mobile communications, they will be primarily paired spectrum for frequency division duplex (FDD) operation.
Security is an important feature of all 3GPP radio access technologies, particularly LTE, which provides security in a similar way to its predecessors UMTS and GSM. In LTE, two functions are provided for the maintenance of security. The first is ciphering, which is used in order to protect data streams from being received by a third party, and is generally utilised for both control plane data and user plane data. The second is integrity protection, which allows the receiver to detect packet insertion or replacement, and is utilised for control plane data.
In the Evolved Packet System (EPS) security architecture, there is a secure communication link between the Mobility Management Entity (MME) and User Equipment (UE), and a secure communication link between the evolved NodeB (eNB) and UE. Generally, MME security is utilised to protect Non Access Stratum (NAS) signalling, whereas eNB security is generally utilised to protect both control plane and user plane communications links.
The subscriber-authentication function in LTE/3GPP EPS is based on the UMTS authentication and key agreement (UMTS AKA) protocol. This protocol provides mutual authentication between the UE and the core network, ensuring robust charging and guaranteeing that no fraudulent entities can pose as a valid network node. It should be noted that some systems, for example GSM Subscriber Identity Modules are not allowed in LTE because they do not provide adequate security.
EPS AKA provides a root key from which a key hierarchy is derived. The keys in this hierarchy are used to protect signalling and user plane traffic between the UE and network. Generally, the security process starts with the UE sending its identity (e.g. IMSI) to the MME, and then the MME sending the IMSI to a Home Subscriber Server (HSS) for authentication. For every subscription stored there is a corresponding security key ‘K’ stored and protected within the HSS, as well as being stored on the Universal Subscriber Identity Module (USIM) in the UE.
FIG. 1 illustrates a simplified block diagram of the EPS security architecture as defined in the art. The HSS 102 is required to produce an EPS authentication vector 106 from EPS authentication module 104, which is used to enable mutual authentication between the UE and the network. Generally, the USIM and the Authentication centre (AuC) component of the HSS implement a common security algorithm that has been selected by a network operator, for example MILENAGE, which is used to produce the EPS authentication vector 106. An EPS authentication vector 106 is produced in the EPS authentication module 104 from inputs K 108 and RAND 110. K 108 is a security key and RAND 110 is a bit stream that is created locally by the AuC. After the EPS authentication vector 106 has been generated, it is passed to the MME 112.
The EPS authentication vector comprises four main elements, being:
random number or random challenge RAND 110,
expected response (XRES) produced with inputs from RAND 110 and K 108,
authentication token (AUTN), and
intermediate key KASME that is used by MME 112 to derive further keys.
The MME 112, receives the EPS authentication vector 106 from the HSS 102 and stores the expected response value XRES, and forwards RAND and AUTN to eNB 114. The eNB 114 transmits 116 RAND and AUTN over an air interface to UE 118. The UE 118 uses the permanent key ‘K’, which, as discussed above, is securely stored on the USIM and in the HSS, and RAND to locally produce key KASME 117 in EPS authentication module 120. Further, the UE 118 compares a locally generated version of AUTN with the signalled version of AUTN from the eNB 114. If the local and received values of AUTN are in agreement, then the UE 118 has authenticated the network. Assuming the UE 118 has authenticated the network, the UE transmits a response RES 122 to the MME 112. The MME 112 compares the received value of RES 122 with the stored value of XRES in module 130. If the value of XRES and RES are in agreement, then the UE 118 has been authenticated by the MME 112. The abovementioned process is referred to as the Authentication Key agreement (AKA) procedure.
After the AKA procedure, the next stage in the security process is to derive keys that are to be used to secure communications links between the UE 118 and the network. Within the EPS security architecture of FIG. 1, there are two main groups of security algorithms employed to derive keys used to secure communications links between the UE 118 and the network. The first group of security algorithms are EPS integrity algorithms (EIA) 132 that are used to integrity protect signalling messages, for example NAS signalling and RRC signalling, that are sent from/to the MME 112 (or eNB) and the UE 118. Generally, the EIA produces a bit stream or message authentication code (MAC) that is attached to the message before transmission, wherein the bit stream is a function of the message. If the message has been interfered with, then the receiving EIA may produce a different MAC. The second group of security algorithms are EPS encryption algorithms (EEA) 134 that are used to cipher the plain text of both signalling and user data.
FIG. 2 illustrates an EPS key hierarchy as defined by 3GPP. The permanent key ‘K’ 108 is stored in the USIM and AuC of the HSS 102, and is situated at the top of the key hierarchy. The parameters CK, IK 205 are derived using K 108 and, in this example, comprise the cipher key (CK) and the integrity key (IK), which are generally 128 bits in length. The key KASME 117 and all its derivatives employ a common algorithm referred to in this example as key derivation function (KDF) 136.
The key KASME 117 is utilised by the MME 112 and UE 118 to derive keys for NAS integrity protection and NAS ciphering (KNASint 138 and KNASenc 140). The MME 112 and UE 118 derive the eNB key KeNB 113 and next hop (NH) 211, which is used to provide forward security.
Referring back to FIG. 1, the MME 112 transmits 142 key KeNB 113 to the eNB 114 and requests a secure signalling connection be established with the UE 118 over the air-interface. The eNB 114 derives the keys KRRCint 144, KRRCenc 146 and KUPenc 148. Further, the UE 118, as part of the security procedure, derives the same identical keys as the eNB 114 namely, KRRCint 144, KRRCene 146 and KUPenc 148.
In order to utilise the abovementioned generated keys, they may require activation prior to use. After the AKA procedure has been completed, the MME 112 may activate security in the MME 112 by running, for example, a security mode procedure. In this example, the MME 112 transmits a message security command to the UE 118, which may be integrity protected using key KNASint 138. The UE 118 may check the validity of this message, and subsequently transmit a message security mode complete to the MME 112, which may be both integrity protected and ciphered using the keys KNASint 138 and KNASenc 140. If these keys are received correctly, the connection between the UE 118 and MME 112 is now secure. In this example, the eNB 114 may activate security at the RAN level by running an initial security activation procedure, and deriving the keys KRRCint 144, KRRCenc 146 and KUPenc 148. Upon receipt of the message security command, the UE 118 may also derive the same set of keys KRRCint 144, KRRCenc 146 and KUPenc 148 using a locally generated version of KeNB 113. In this example, the UE 118 may respond to the eNB 114 with the message security mode complete that may be integrity protected using the key KRRCint 144 but that may not be ciphered. In this example, a secure signalling connection may now have been established at the RAN level plus ciphering may have been established for user plane bearers. In FIG. 1, the secure signalling connections are shown as dashed lines between the peer EIA 132 and EEA 134 entities.
In summary, the abovementioned procedure relies on a close interaction between the UE 118 and the network. The permanent key ‘K’ 108 is only stored in the HSS 102 and USIM of the UE 118, and is never transmitted anywhere else in the network. This is to preserve the shared ‘secret’. All the keys disclosed in FIG. 2 are derived from permanent K 108 and the algorithms for deriving network keys are common across all network elements, including the UE 118. Generally, the EPS AKA, key hierarchy and procedure for activating keys requires interaction between the UE 118 and other network elements.
In some instances, it may be advantageous for two or more UEs to communicate directly without the use of the abovementioned network structure. This may be, for example, when the two or more UEs desiring communication are outside of the radio coverage provided by the network infrastructure. An example application for direct mode operation (DMO) could be for the public safety market.
However, implementing direct mode operation using the abovementioned architecture is not currently possible, due, in part, to the use of the permanent key ‘K’ in the art. It has already been discussed that the permanent key ‘K’ is only stored in the USIM of a UE and the AuC of a HSS. Therefore, the currently defined architecture cannot be utilised for DMO. For example, utilising the abovementioned architecture, a UE desiring DMO would need to store the permanent keys for all UEs that it may have a DMO communication with, which is unfeasible. Further, the transmission of the permanent key ‘K’ to other UEs could compromise security of the network, as the permanent key ‘K’, currently, is never transmitted over the network. Further, if a UE is not connected to the network, there is currently no way for this UE to determine the key hierarchy defined in FIG. 2.
Therefore, there is a need to provide DMO authenticated and secure communications between UEs, utilising the current abovementioned architecture, whilst overcoming the problem of utilising a permanent key ‘K’ that cannot be transmitted through the network.